A database is an organized collection of data. Databases commonly organize the data into spaces, tables, indexes, columns, and rows. For example, a column (also referred to as a field) may represent an individual datum, such as a first name or a last name. Columns having some relation are stored together in a table. For example, a first name, last name, birthdate, and address field may be stored together in a table that describes a person. The actual instances of data are stored in a row. In the example above, “Judy” “Smith” “Oct. 2, 1975” may be a row in the described table. An index stores a subset of the columns in a table and is used to more quickly access a row of the table. Related indexes are often stored in an index space and tables having some relation are often stored together in a table space. For example, a person table may be stored with a class schedule table and a class history table in an enrollment space for a student at a university, while an admissions space may contain data collected during the admissions process. The structure of the database objects (e.g., the columns, tables, indexes, and spaces) is often stored in a database catalog. The catalog contains data about the objects such as an owner, the format, an object identifier, a date of the last structure change, how the objects are related, etc.
Organizations often keep multiple instances of data for various purposes. For example, it is a common practice to have a production version of a database and a test version of the same database. The test version may be used by the organization's application developers or quality assurance testers to create data for test cases used to debug and test the applications under development. In other situations, an organization may have a day-old (or week-old) copy of a production database that is used for training or for generating reports so that such activities do not impact the data and response time for users of the production database. In most cases, such additional database instances have the same or almost the same table structure as the production database.
To populate an additional database instance from an original database (i.e., the source), an organization may unload the data from the original database into a flat file, and then use the flat file to reload the additional database instance (i.e., the target). This method can be version agnostic because the columns of the source table can be rearranged, massaged, or otherwise converted into the format of the target table. However, the unload/reload process is slow and processor intensive, making the process expensive. Furthermore, the practice usually requires that the indexes be rebuilt to maintain consistency with the data. This incurs more processor time and, thus, more expense.
To avoid the costs associated with the unload/reload approach for data migration, database administrators may use an image copy approach. Image copies of a database are a snapshot in time of the data in the database and are often used for recovery purposes (e.g., for recovering a table that has become corrupted). Utilities for creating an image copy of a database are typically installed with the database. While creation of an image copy and the migration of the copy to the target database are relatively fast, the use of this process for data migration has been limited. For example, for a successful data migration from an image copy, the source and target tables must have compatible column definitions and the version information must be complete. If the column definitions or version information are not compatible, the data will not migrate correctly into the target database. Furthermore, object identifiers must be translated manually, a process prone to typographical errors and other mistakes. For these reasons, image copies are not typically used for data migration from, for example, a production to a test environment.
Thus, a need exists for a system and method for populating additional instances of a database with an image copy that reduces manual input, reduces processing time, and increases successful migration outcomes.